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(54) Abstract Title 

Line information security interface for TAP! service provider 

(57) A system provides a secure interface to a PBX system 224 comprising a PBX having a command 
executor 220. A plurality of telephony devices 218 and one or more programmable computing devices 202 are 
connected to the PBX. Each programmable computing device has a telephony service provider component 
212 which communicates vwth the PBX command executor through a PBX command interface 216 resident on 
the programmable computing device to request and obtain a list of telephony device identifiers corresponding 
to a set of telephony devices which are permitted to be monitored or controlled by the programmable 
computing device. 
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At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy 

This print takes account of replacement documents submitted after the date of filing to enable the application to comply 
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ro 

CO 



2341291 

LINE INFORMATION SECURITY 
INTERFACE FOR TAPI SERVICE PROVIDER 

FIELD OF THE INVENTION 

This invention relates generally to the field of telephony and more specifically 
to a messaging interface that automatically provides a telephony service provider with 
detailed information about any selected line device. 

BACKGROUND OF THE INVENTION 

With the advent of more sophisticated computer technology infi^tnicnires, 
there has been a movement toward facilitating and implementing telephony fimctions 
on desktop computers. On desktop computers, telephony fimctions are provided by a 
desktop computer application, which communicates through a telephony line manager 
interface, which in turn, communicates with a telephony service provider that 
provides the telephony line. The telephony service provider communicates with the 
telephony equipmwit, such as a PBX, to provide the SCTvice. One example of a 
telephony service provider is the Mitel PBX TAPI Service Provider. 

A telephony line is a line device with at least one address. POTS, or Plain 
Ordinary Telq)hone Sets, have only one address as their primary Directory Number 
(DN). Digital telephone sets also possess a primary DN; however, they can have 
other addresses that typically describe line ^jpearances of other sets. 

The Telephony Application Programming Interface (TAPI) specification of 
Microsoft® Windows™ is an example of a telephony line manager interface that 
provides first party call control to applications on desktop computers. Through a 
telephony line manager interface, like TAPI, qjplications can make calls, be notified 
about calls, answer calls, hold calls, and perform other switch related fimctions as if 
the application were the end-point of the call. 
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Personal computer programs that offer Personal Information Management 
(PIM) like Microsoft's Outlook, and Lotus Organizer, utilize the functions of a 
telephony service provider by means of the telephony line manager interface, the 
telephony service provider passes data through the telephony line manager, whose 
5 interface allows an application to present detailed call information on the user's PC. 
Moreover, the telephony service provider enables the application software to initiate 
outgoing calls from the user's PC with a simple click of the mouse. Thus, the personal 
computer application and telephony line manager interface are dependent on the 
services provided by the telephony service provider. 

10 

The telephony service provider can reside on the desktop PC and operate in a 
stand-alone mode by communicating directly to telephony equipment like a PBX. 
The stand-alone telephony service provider typically offers a personal computer 
application control over a single line or device, namely the PC user's desktop 
15 telephone set. As an alternative, the telephony service provider can reside on a 

network-accessed server and provide a client/server mode of operation. The server- 
based telephony service provider typically controls many line devices on behalf of 
chent computer applications. 



20 Many stand-alone telephony service providers are unable to retrieve the 

detailed information about the line devices under their control from the telephony 
equipment they communicate with. In some implementations, the telephony service 
provider requires the PC user manually configure the details of the devices that it is 
allowed to control. Amongst the details is the list of Directory Nimibers (DNs) that 

25 belong to the line device. There is no security to prevent the PC user from entering 
any DN. In many circumstances, the telephony equipment, such as a PBX, lacks the 
security to prevent the telephony service provider from controlling any specific line 
device. This implies that the user can select any telephone line to monitor and 
control, which poses a potential breach of security. 



The issue of security is more acute for stand-alone telephony service providers 
than it is for server-based telephony service providers. A PC user typically has frill 



administrative control over a stand-alone telephony service provider that resides on 
his or her own PC. A server-based telephony service provider is generally more 
secure because access to the server is typically limited to an authorized administrator 
by password control and possibly physical lock and key.. A server administrator has 
the authorization and level of security to limit what line devices (and hence the list of 
DNs) a client application program can monitor and control. 

Because the senrer-based telephony service provider has access to many line 
devices (telephone sets), an administrator is still required to manually configure the 
list of devices that each clioit conq>uter is allowed to monitor and control. Aside 
from the requirement of manually configuring the primary DN that identifies each line 
device, the administrator may have the added burden of configuring all the detailed 
information for each line device. Additional Directory Numbers that represent 
addresses (or line appearances) would be amongst this additional detailed information 
required against each line device. 

SUMMARY OF THE INVENTION 

A mechanism is needed for a telephony service provider to acquire detailed 
information about a line device it can monitor and control fiom the telephony 
equipment. Such information provided to the telephony service provider should 
include a the list of Directory Numbers (DNs) sq>ported by a Une device, and 
optionally, other ancillary information. The telephony service provider should also be 
able to provide this information to a requesting plication utilizing the services of the 
telephony service provider. 

For a stand-alone telephony sovicc provider controlling a PC user's desktop 
telephone, this offers two benefits. First, it removes the PC user &om the burden of 
configuring his telq)hony service provider with the details of his telephone set. And 
second, it improves security by limiting a PC user's control to only his line device (or 
telephone set). There are also benefits a server-based telephony service provider 
controlling many line devices on behalf of cUent computers.. Although a server 
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administrator may still be required to configure the server-based telephony service 
provider with the list of line devices for each client computer, he does not have to 
configure the detailed information that describes each line device. 

Telephony equipment, such as a PBX, typically holds a database with the 
detailed information about each line device. The telephony equipment uniquely 
distinguishes one line device (or telephone) from another by means of an identifier. 
Access to a line device's information can be made by means the unique identifier. 
The hardware connection that links a stand-alone telephony service provider with the 
telephony equipment, such as a PBX, may be used as the unique identifier to uniquely 
identify the line device to be controlled. In a preferred embodiment, it is the hardware 
connection between the telephony equipment and the telephone set, to which the 
stand-alone telephony service provider is physically coraiected to. that is used for this 
unique identification. The unique identifier used to retrieve the detailed information 
about the line devices, such as a telephone set, on behalf of the telephony service 
provider. The list of DNs the telephony service provider is permitted to support is an 
example of the detailed information that can be provided to to the telephony service 
provider, and passed on to the application. 

The hardware connection between the telephony equipment and a telephony 
service provider offers access to aplurality of line devices. The unique identifiers, 
that distinguish line devices on the telephony equipment, are stored in a database for 
access by the telephony service provider. A user, such as an administrator of the 
telephony equipment, or of a server based telephony service provider, configures these 
25 unique identifiers to define the collection of line devices to be associated with client 
computers. The telephony service provider uses these unique identifiers to acquire the 
detailed information of each line device fiom the telephony equipment, such as a 
PBX. The retrieved information determines which DNs (addresses or line 
appearances) a particular Une device is permitted to monitor and control. 
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However, the present invention is not limited to retrieving line appearance 
information. The present invention could be used to retrieve other information based 



upon identifiers such as IP addresses, MAC addresses, trunk ids, or any other 
identifier used to identify devices in the environment. 

Therefore, according to one aspect of the present invention, there is a system 
for providing a secure interface to telephony equipment, such as a PBX system, 
comprising: 

(a) A PBX having a command executor, 

(b) A plurality of telephony devices connected to the PBX; 

(c) One or more programmable computing devices connected to the 
PBX; 

wherein each progranmiable computing device has a telephony service 
provider component which communicates with the PBX command executor through a 
PBX command interface resident on the programmable computing device, to request 
and obtain detailed information coiTeqx>nding to a set of the telephony devices which 
are permitted to be monitored or controlled by the programmable computing device. 

Furthermore, according to another aspect of the present invention, there is 
provided a method for providing a secure intake to a PBX system comprising: 

(a) sending a request for monitorable line appearances from a telephony 
service provider of a programmable computing device to a PBX; 

(b) the PBX sending a list of monitorable line ^earances in response to the 
request to the programmable computing device. 



BRIEF DESCRIPTION OF THE DRAWINGS 

A detailed description of the preferred embodiments is provided herein below, 
with reference to the following drawings in which: 

Figure 1 is a representative block diagram illustrating the telephony 
environment of the present inv«tion; 
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Figure 2 is a representative block diagram illustrating a preferred embodiment 
of the messaging interface using the environment of Figure 1 , 

Figure 3 is a representative block diagram illustrating the telephony service 
5 provider interface with the PBX command interface of Figure 2. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

10 Turning to Figure 1, a traditional PBX system 102, as is well known in the art, 

is illustrated. PBX system 102 may be connected to numerous other devices and 
servers such as a digital service units, network gateways, application gateways, 
network management servers, voice mail servers, call management servers, call 
accounting servers and public telephone systems (not illustrated). A person of 

15 ordinary skill in the industry will appreciate that numerous other configurations are 
possible. The PBX system 102 incorporates physical hardware and core PBX 
software implementing well known PBX call control functions. The hardware 
components of PBX system 102 typically include a main controller and a plurality of 
fiber interface modules (FIM) which plug into a back plane of the PBX system 102 

20 for multiplexing voice and signaling channels over fiber links to peripheral cabinets 
and devices (not shown). The main controller of PBX system 102 typically includes a 
central processor, memory including disk memory and a disk controller, an Ethernet 
LAN interface providing access to corporate local area networks, a back plane 
intercoimecting peripheral devices, various switching and signaling components, and 

25 conmiunications ports to connect to telephony devices. The PBX system 102 also 

provides line card interfaces, for connecting analog telephone sets 104 and 106, digital 
network interface circuits (DNIC), for connecting digital telephone sets 108 and 1 10, 
as well as trunk card interfaces, for connecting to the outside public switch telephone 
network (PSTN). An SX2000 PBX by Mitel® is a typical example of PBX system 

30 102. 

The PBX system 102 is programmed by a customer data entry interface 



coupled to the PBX system 102, and contains a database for maintaining infonnation 
in structured records, and file system for file storage and retrieval. Software 
components executed within PBX system 102 include call control, management of 
call features, a message switch subsystem providing communication with inteUigent 
nodes, a circuit switch subsystem providing voice channels to the switch matrix, a 
command executor passing commands according to a command language, and 
maintenance software that monitors and tests components in the PBX system 102. 

A telephony server 1 12 may be connected to PBX system 102 via fiber 
connection and utilizing a host command interface to pass information to and fi-om the 
PBX system 1 02 as required. Telephony server 1 12 is a server-based telephony 
service provider that siqiports computer telephony interfaces such as TAPI in order to 
permit third party application developers to monitor and control PBX fimctions within 
the PBX system 102 by connecting as a client to the telephony server 1 12. Telephony 
server 1 12 such as is well known in the art may be connected to a local area network 
122 using well known networking protocols such as Ethernet. Programmable 
computing devices such as personal computes 1 14, 116, 1 18 and 120, may be 
standard personal computers well known in the art running standard operating systems 
such as Windows 95 or 98 by Microsoft. Personal computers 1 14, 1 16, 1 1 8 and 120 
contain various desktop computer plications including applications which perform 
telephony functions that conununicate through a telephony line manager interface 
which in turn conununicates with a telq)hony service provider running either on the 
computer itself or on the telq)hony server 1 12 that provides telephony fimctions. 

Call signal control is provided to applications on desktop computers 1 14, 1 16, 
1 1 8 and 120 through a telephony line manager interface, such as TAPI. Using a 
telephony line manager interfece, like TAPI, applications can make calls, be notified 
about caUs, answer calls, hold calls and perform other switch related fimctions as if 
the appUcation were the end point of a caU. Using a telephony line manager interface, 
like TAPI, an application can access multiple telq>hone lines, with one or more 
addresses associated with each line. An address can be referred to as directory 
number PN). Each line has an address and each address can have one or more calls 
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associated with it and each line may monitor or control one or more other addresses 
simultaneously. Personal computers 114 and 1 16 are connected to a local area 
network 122 using standard networking interfaces such as Ethernet to communicate 
with telephony server 112. Telephony server 1 12 can then filter, format, receive and 
serve telephony functions to personal computers 1 14 and 1 16 through its interface to 
PBX system 102 and local area network 122. Personal computer 118 may be 
connected to digital telephone 1 10 through a communications line or port such as a 
RS232 or USB interface. Digital telephone 1 10 then connects to PBX system 102 
using a standard digital telephone line. Personal computer 120 may be directly 
connected to PBX system 102 using a standard analog or digital telephone Une. 
Telq>hony applications on personal computers 114 and 1 16 send and receive 
messages to PBX system 102 through a messaging interfece to through local area 
network 122 utiUzing the services of telephony server 1 12. The messaging interface 
is further illustrated with respect to Figure 2. Alternatively, personal computer 1 1 8 
sends and receives messages to PBX system 102 using the messaging interface 
through telephone 110. Alternatively, personal computer 120 sends and receives 
messages from PBX system 102 using the messaging interface through a direct 
connection to PBX system 102. The messaging interface allows personal computers 
1 14, 1 1 6, 1 1 8, 120 or any other appropriately configured electronic computer device 
adapted to utilize the messaging interface to send and retrieve control and monitoring 
information regarding any telephony device such as analog telephones 104, 106 or 
digital telephones 108, 1 10 or any other telephony device connected to PBX system 
102. 

Turning to Figure 2, the typical messaging interface between a personal 
computer, to a PBX system of Figure 1 is fiuther illustrated. In the example of Figure 
2, the messaging interface is provided through a digital telephony. Personal computer 
202 has running within it one or more desktop appHcations 204 that provide telephony 
fimctions. Desktop appUcation 204 communicates to a telephony line manager such 
as TAPI 208 through interface 206. TAPI 208 communicates with the telephony 
service provider such as TAPI SP 212 through interface 210. TAPI SP 212 
communicates to the PBX command interface 216 through interface 214. The PBX 



command interface sends and receives commands from the PBX command executor 
220 of PBX system 224 via connections through digital telq)hone 218. PBX 
command executor 220 communicates with the hardware and software of PBX system 
224 through interface 222. 

The applications and interface 204 to 216 in personal computer 202 would 
operate in a similar manner on each of the personal computers 1 14 to 120 of Figure 1 
in a manner readily apparent to one skilled in the art. Although personal computer 
202 is connected to the PBX system 224 through a communications interface such as 
RS232 or USB on a standard digital teIq)hone set, personal computer 202 could be 
connected to PBX system 224 in any manner such as well known in the art including 
those illustrated in Figure 1. 

hi a preferred embodiment, the PBX system 224 is a Mitel SX2000. In the 
preferred embodiment, the command executor 220 and PBX command interface 216 
use a command language such as q2000 by Mitel to support the connection of 
telephony service providers (TAPI SP 212) to the PBX system 224. The command 
language provides sufficient infomiation to monitor and control calls in the PBX 
system 224. As an alternative, a PC may be connected to PBX system 224 through a 
link to an apphcations gateway or a conmiunications card and digital telephone 
dataset. The use of a command language such as q2000 pennits commands and 
messages to be sent from the personal conq>uter 202 through the telephone 2 1 8 to the 
PBX system 224 using the telqjhone line cmnection. In the preferred embodiment, 
the personal computer 202 is connected to a 4000-series Mitel telephone 218 which 
acts as a intermediary between the PC and the PBX system 224, A direct connection 
between the personal computer 202 and the PBX system 224 could alternately be 
provided. 

In order to send fimctional information betwem the PBX system 224 and the 
personal computer, the MINET protocol is used as the network layer protocol, 
although other protocols could be used. 
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Turning to Figure 3, the TAPI SP interface with the PBX conimand interface 
of Figure 2 is further illustrated. TAPI SP302 communicates to PBX command 
interface 306 through interface 304. PBX command interface 306 contains the 
necessary facilities to provide communications to the PBX. In the example of Figure 
5 3, the PBX command interface 306 provides communications with a Mitel SX2000 
PBX and contains a MiTAI layer 308, an endian/hci/asn. 1 layer 310 and a MINET 
layer 312 for communication with the PBX. MITAI can be implemented as a 
client/server layer that provides routines and data retrieval macros for the TAPI SP 
302. 

10 

In the preferred embodiment illustrated, the size of Q2000 messages could be 
reduced in size using standard compression algorithms to be passed between the PC 
and the PBX. 

15 The following illustrates one example of how requests and responses can be 

passed from the personal computer application and the PBX system 3 1 6. 

The desktop application communicates with the TAPI SP 302 via TAPI to 
obtain infomiation from the PBX 316 and to control PBX resources. The TAPI SP 

20 302 receives TAPI requests from the desktop application and interfaces with the 

MiTAI 308 server process to process the TAPI requests. The TAPI SP 302 initiates a 
request for the PBX 3 1 6 to MITAI 308. In the preferred embodiment, the TAPI SP 
302 is a MITAI client rurming in the same Windows or Windows 95 envirorunent as 
the MITAI 308 server process. The MITAI 308 server process generates an ASN. 1 

25 formatted HCI message which, when passed to the HCI/endian/ASN. 1310 layer, is 
converted to a q2000 message. When different processors are rurming in the personal 
computer and the PBX system 316, the q2000 messages to be sent and received by the 
personal computer must be Endian converted due to the different maimer in which 
each processor manages instructions and data formats (Motorola vs Intel). 

30 

The Q2000 messages are then placed into MINET Datagrams (MINET 
encapsulation) before sending the data to the PBX system 316. MINET Datagrams 
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act as the Layer 3 (network layer) protocol mechanism. This permits the requests and 
responses to be passed through a telephone line as necessary to the PBX system 316. 

To provide a secure service to the personal computer application, each 
telephony service provider (TAPI SP 302) needs to know about all the programmed 
DNs or line appearances on the associated telephone or device. This is preferably 
done at TAPI SP initialization. This information is required so that the TAPI SP 302 
can establish a monitor on each line appearance without the need for having the user 
manually enter the number of each line ^>pearance through the existing TAPI 
programming interface provided by Microsoft. 

Line appearance information gathering is triggered by the personal computer 
TAPI ^plication sending a TSPIJineGetDevC^s to the TAPI SP 302. The TAPI SP 
302 then issues a request to the PBX command interface 306 who, in turn, sends a 
translate_All_Monitorable_Lines request to the PBX software. The request contains 
the id of the sending line used by the personal computer cormection. The PBX system 
3 1 6, upon receipt of the request 318, scads back a response 320 of a list of line 
appearances which the sending line is addressed to monitor or control. 

The following illustrates how the line ^earance gathering activity would 
work in a Mitel environment using a Mitel SX2000, MiTAI, MINET and the q2000 
language. 

A new translate command is used to allow the TAPI SP 302 to request 
translate information on all line ^jpearances of a given set. A new q2000 translate 
code, such as q2000_fc_translate_all_monitorablejines, would be received and 
processed by the command executor (Q2000) software on the PBX system. The 
Endian/HCI/ASN.l layer 310 would perform a translation request using the following 
data structure: 

Translate OPERATION 

ARGUMENTSEQUENCE 
addressing Addressing-info, 
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trans-type ld_alljmonitorableJines Directory-number 

The Directory-number parameter can be a null string. It is expected that a 
stand-alone TAPI SP will set this field to a null string, but a TAPI SP on a telephony 
server will send a non-nil directory number. Upon receipt of a 
q2000_fc_translate_all_monitorable_lines request 318 with a null directory number, 
the PBX will automatically provide translate information on the line device connected 
to the TAPI SP. For a stand-alone TAPI SP, the PBX system 316 uses the unique 
identifier for the hardware line to determine which translate information to provide. 



In an alternate embodiment, the optional Directory-nimiber field is designed 
for a telephony application server like Mitel's Applications Gateway which has no 
associated directory number, device or telephone set. Programs nmning on a 
telephony ^plication server can also iise this new translate feature to obtain translate 
15 information for all line appearances on any programmed DN or line on the PBX. 

If the PBX is unable to provide translate information, a 
q2000_erT_invalid_parameter_value will be returned. The corresponding 
Endian/HCI/ASN.l layer 310 return code is INVALID_TRANS_VALUE_C. An 
20 example of when this error code is returned is when an Applications Gateway sends a 
Translate All Monitorable Lines request to the PBX with an invalid or unprogranmied 
Directory Number. If an Applications Gateway sends a Translate All Monitorable 
Lines request with a null string, a q2000_err_unsupported_target error will be 
returned. 



The PBX will send a single translate response 320 result containing, for 
example, the button number and extension of each monitorable line appearance for the 
telephone line or DN. The first extension in the list will be that of the prime extension 
or DN making the request. 

For example, the Translate result to the PBX command interface 216 could be 
defined with a data structure as follows: 
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Translate OPERATION 

RESULT SEQUENCE 
addressing Addressing-info, 
5 desc Logical-descriptor 

Logical-descriptor 

lid Logical-equipment-id 
info Logical-device-info 

10 

If no Directoiy-number is q)ecified in the request 318 to the PBX, then the lid 
in the response message 320 will be the logical equipment id of the line or DN 
connected to the TAPI desktop plication personal computer. If the optional 
Directory-number field is specified, then the lid will be that of the device associated 
15 with the Directoiy-number. 

In this example, the information in the response 320 returned to the desktop 
computer is defined as follows: 

20 monitorable_lines_info 

number_of_monitorable_lines byte 

linel optional Jinedata 

line2 optionalJine_data 

25 

linel6 optionaMinedata 

In this example, 16 diffoent line appearances can be described in the 
monitorable__lines_info data structure. 

30 

The first line appearance in the data (line 1) will always be the prime line of 

the phone or device connected to the requesting stand-alone TAPI SP. Each 

optional Jine_data entry will contain the following information: 

lid Iogical_equ^entJd 
35 extension_number Directoxy_jiumber 

If the plication wishes more infonnation regarding a particular monitorable 
extension, then an additional information request must be sent to the PBX. It is 
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expected that the application will send a request 318 to the PBX with the prime 
number of the set to obtain name information and device type information. 

An example of a translate-all-monilorable-lines result implemented in a Mitel 

5 environment is as follows: 

Operation = Translate 
A2 49 30 47 || 
02 01 II 

04 II Invokeld Integer(4) 

10 30 42 II Result Sequence 

7E 06 II Addressing Addressing 

53 01 II DataLost Null(Absent) 

00 II InvokeAddr Address(O) 

53 01 00 II ServerAddr. Address(0) 

1 5 SequenceNum Word(ABSENT) 
66 38 

54 04 7D 00 II Lid Lid(2097152013) 

00 OD II 

BI 30 Info LogicalDevInfo 

20 MonitorableLineData MonitorableLineDatalnfo 

50 01 03 II NumberofMonitorableLinesByte(3) 

7F 2D OC II linel MonitorableLineData 

54 04 7D 00 II Lid Lid(2097152013) 

00 OD II 

25 55 04 31 32 II ExtensionNumber..... DirectoiyNumber: 1222 

7F 2D OC II Iine2 MonitorableLineData 

54 04 7D 01 II Lid Lid(20972 17549) 

00 OD II 

55 04 31 32 11 ExtensionNumber DirectoryNumber: 1224 

30 32 34 II 

7F 2D OC II line3 MonitorableLineData 

54 04 7D 04 1| Lid. Lid(2097414157) 

00 OD II 

55 04 35 35 || ExtensionNumber DirectoryNumber 5555 

35 35 35 II 

II line4 MonitorableLineData(ABSENT) 

II lines MonitorableLineData(ABSENT) 

II line6 MonitorableLineData(ABSENT) 

II line? MonitorableLineData(ABSENT) 

40 II lines MonitorableLineData(ABSENT) 

II line9 MonitorableLineData(ABSENT) 

II linelO MonitorableLineData(ABSENT) 

II linell MonitorableLineData(ABSENT) 

II linel2 MonitorableLineData(ABSENT) 

45 II linel3 MonitorableLineData(ABSENT) 
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II 
II 
II 



Iinel4 MonitorableLineData(ABSENT) 
linelS MonitorableLineData(ABSENT) 
linel6 MonitorableLineData(ABSENT) 



In an alternative embodiment, the present invention could be used to simplify 
the existing initialization sequence for the server-based TAPI SP. Today, an 
administrator must enter all DNs that each user can monitor and control, including 
each prime DN and each line J^earance DN. This could be simplified such that the 
administrator need only enter the prime DN that each user can monitor and control. 
The TAPI SP can then send a request to the PBX and receive a response of a list of 
line appearances programmed on each phone. Each user would be allowed to monitor 
and control any or all of the appearances on the phone. 

The preferred embodiment of this invention uses the id of the line or DN as the 
key identifier (prime line or DN) for each TAPI SP connection. In an alternate 
embodiment, the telephone can be replaced with any other unique piece of hardware 
including a dataset, a modem, or a piece of proprietary hardware (like Mitel's Talk-to 
card which emulates a telephone) that has its own unique identifier. Any piece of 
hardware that can be programmed on the PBX as a unique device and can support a 
connection to a PC (viaRS-232, USB, TCP/IP, ethemet, ATM, fi^e relay, or any 
other well defined computer interface) can be used with this invention. Such 
hardware could be identified by IP address, MAC addresses, trunk id or any other 
suitable conq)uter or telephony idmtifer, and suitable information about such 
hardware could be returned in the re^xmse 320 fiom the PBX system. 

Although the invention has been described in temis of flie preferred and 
several altemate embodiments described herein, those skilled in the art will ^preciate 
other embodiments and modifications which can be made without departing &om the 
spirit and scope of the teachings of the invention. All such modifications are intended 
to be included with the scope of the claims 2q>pended hereto. 
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THE EMBODIMENTS OF THE INVENTION IN WHICH AND 
EXCLUSIVE PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS 
FOLLOWS: 

5 

1 . A system for providing a secure interface to a PBX system comprising: 

(a) a PBX having a command executor, 

(b) a plurality of telephony devices coimected to said PBX; 

(c) one or more programmable computing devices connected to said PBX; 
10 wherein each said programmable computing device has a telephony service 

provider component which communicates with said PBX command executor 
through a PBX conunand interface resident on said programmable computing 
device to request and obtain a list of telephony device identifiers 
corresponding to a set of said telephony devices which are permitted to be 
15 monitored or controlled by said programmable computing device. 

2. The system of claim 1 where said telephony device identifiers comprises line 
appearances. 

20 3. The system of claim 1 where said telephony device identifiers comprises IP 
addresses, MAC addresses, trunk identifiers and computer identifiers. 

4. The system of claim 1 wherein said programmable computing device is 
connected to said PBX through one of said telephony devices. 

25 

5. The system of claim 1 wherein said programmable computing device is a 
personal computer. 



6. 

30 



The system of claim 1 wherein said programmable computing device monitors 
and controls said telephony devices indicated on said list. 



17 



The system of claim 1 wherein said programmable computing device is a 
telephony server. 

A method for providing a secure interface to a PBX system comprising: 

(a) sending a request for monitorable line appearances from a telephony 
service provider of a programmable computing device to a PBX; 

(b) said PBX sending a list of monitorable line ^earances in response to said 
request to said programmable computing device. 

The method of claim 8 wherein said request and response are sent through a 
PBX conunand interface resident on said programmable computing device for 
translation to and from PBX command language format respectively. 

The method of claim 8 wherein said request is received, processed and said 
response provided by a command executor resident on said PBX. 

The method of claim 8 wherein said programmable computing device is a 
personal computer. 

The system of claim 8 wherein said progranmiable computing device is a 
telephony server. 
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